Programación Orientada a Objetos

PROGRAMACIÓN
ORIENTADA A
OBJETOS

“La nueva cultura de desarrollo de software” (Bertrand Meyer)

“Todo es un objeto” (Alan Kay)

“Un objeto tiene estado, comportamiento e identidad” (Grady Booch)

El Paradigma de los Objetos
La Programación Orientada a Objetos (POO) es un paradigma de programación que utiliza los objetos como abstracción principal. Un objeto es un componente software integrado por datos y código. Está formado por varios procedimientos (llamados métodos) mediante los cuales se accede a los datos internos del objeto. Los objetos se comunican entre sí mediante mensajes.

La POO ha emergido con fuerza en los últimos tiempos y se considera como un gran avance en la ingeniería de software, comparable a lo que supuso en su día la programación estructurada. Algunos la han presentado como una panacea y como el “paradigma definitivo”. Por su difusión y popularización se le ha calificado como “La nueva cultura del desarrollo de software” [Meyer, 1990].

El mundo del software está construido principalmente sobre la POO. Esto incluye aplicaciones web, software empresarial, protocolos de red, etc.

Conceptos de la POO

Clase.
Una clase es un tipo de objetos. Es una “plantilla” generadora de objetos.
Objeto.
Un objeto es una instancia de una clase.
Mensajes.
Es el sistema de comunicación entre los objetos. Los objetos se comunican dinámicamente en tiempo de ejecución. Mediante los mensajes los objetos se pueden crear, modificar y destruir dinámicamente.
Atributos.
Son los datos internos de las clases y de los objetos.
Evento.
Es un suceso interno o externo producido en el sistema como una interacción del usuario, un mensaje enviado por un objeto o la reacción producida en el objeto receptor.
Método.
Es un procedimiento asociado a una clase y que se ejecutan por la recepción de mensajes. Los métodos de una clase lo heredan los objetos de esa clase y las clases de rango inferior (subclases).
Encapsulamiento.
En los objetos se utiliza la abstracción de datos. Es decir, los datos internos de un objeto se ocultan al usuario. El usuario solo puede acceder a ellos a través de los métodos, que constituyen la interfaz pública.
Herencia.
Las clases se estructuran en forma de árbol jerárquico. Las clases superiores son más generales y las inferiores son más particulares, de detalle. Una clase hereda los atributos y métodos de las clases superiores. Se puede hablar de superclases y subclases, superobjetos y subobjetos.
Comportamiento de un objeto.
Está definido por los métodos que se activan como respuesta a los mensajes recibidos. Este comportamiento puede ser interno (modificación de los atributos internos) o externo (envío de mensajes a otros objetos).
Polimorfismo.
Es la capacidad de un objeto de exhibir diferentes comportamientos en función de los argumentos pasados a los métodos. Un objeto puede recibir diferentes tipos de mensajes. Un mismo mensaje puede producir diferentes efectos en objetos diferentes. Permite operaciones con el mismo nombre pero diferente semántica en función de los argumentos. Es lo que se denomina “sobrecarga” (semántica).
Estado de un objeto.
Es el formado por un conjunto de atributos (pares de nombres-valores) de ese objeto.
Identidad.
Es un atributo, propiedad o identificador de un objeto que lo diferencia del resto.
Propietario.
Se rechaza el acceso directo a los datos comunes. Solo el propietario de un dato (sea común o no) puede cambiar el dato. Otros objetos pueden acceder o cambiar los datos enviando un mensaje al objeto propietario.
Ligamento o enlace dinámico (dynamic binding).
Es la capacidad que tiene un objeto de decidir a qué otro objeto envía un mensaje y que método en concreto debe ejecutarse.

Ventajas de la POO

Mayor nivel semántico.
La POO representa una mayor aproximación al modelo de la mente, pues es mayor el nivel semántico al pensar en términos de:
1. Objetos.
  El objeto es un patrón mental básico asociado al lado derecho del cerebro.
2. Clases.
  En este segundo aspecto, se trata de pensar, no sólo en objetos, sino también en términos de tipos o clases, es decir, con categorías. Esto supone conectar con otra característica básica de la mente: la de asociar cada objeto con una o varias categorías, de las que el objeto es un caso particular.
3. Abstracción de datos.
  Con este mecanismo se proporciona una distinción entre la especificación (el “qué”) y la implementación (el “cómo”). El “qué” implica un nivel de conciencia superior al “cómo”, que es un nivel de detalle.
Integración datos-procesos.
En POO, objetos y clases integran atributos (datos) y métodos (procesos).
Generalización.
La POO fomenta la generalización, al crear objetos y clases independientes de los proyectos, más generales que lo que sería necesario para resolver un problema concreto.

La POO se puede considerar como la búsqueda de los desarrollos genéricos a través de procesos de abstracción de clases y objetos. Las clases y objetos son tanto más genéricos cuanto mayor es su nivel en la jerarquía.
Reutilización.
En POO se pone énfasis en un diseño basado en módulos o componentes reutilizables en diferentes sistemas software.

La herencia promueve la reutilización al permitir crear nuevas clases mediante adiciones (de nuevos atributos y métodos) y sustituciones (de los atributos y métodos heredados) de dos formas:
1. Ascendente. Las clases se amplían para darles mayor generalidad.
2. Descendente. Las clases se especializan para adaptarlas a casos particulares.
Flexibilidad de ejecución.
El objeto y el método a ejecutar se determina en tiempo de ejecución.

Inconvenientes de la POO

Falta de base teórica.
No existe una base teórica ni una definición formal y rigurosa de la POO. Diferentes lenguajes de programación lo interpretan de diferente manera. No hay una relación directa entre paradigma POO y LOO (Lenguaje Orientado a Objetos). No se ha alcanzado una definición consensuada de una teoría de objetos.
Paradigma restrictivo.
La POO limita gravemente la libertad, la expresividad y la creatividad al imponer la abstracción de clases y objetos, así como una estructura jerárquica de clases. Las abstracciones a utilizar (procedimientos, funciones, objetos, eventos, aspectos, etc.) deben de reflejar la estructura del problema. No debe imponerse una abstracción “obligatoria”. Un paradigma es solo una ideología, una forma de ver las cosas. Pero hay muchas formas de ver las cosas.

La POO puede ser un modelo útil en ciertos casos, como modelar los objetos del mundo real. No se puede usar la misma herramienta para todos los problemas. Problemas diferentes requieren herramientas diferentes. Hay que elegir el paradigma adecuado para cada parte del problema. “A veces la implementación elegante es solamente una función. No un método. No una clase. No un marco. Solo una función” (John Carmarck, programador de juegos).
Complejidad.
Los lenguajes orientados a objetos son complejos, requieren una curva de aprendizaje larga y son difíciles de usar. “El diseño orientado a objetos son los numerales romanos de la computación” (Rob Pike, uno de los desarrolladores del sistema Unix).

La tarea de programar con el enfoque de objetos es compleja por las siguientes razones:
1. El aprendizaje de un LOO exige conceptualizar todos los elementos como objetos. Esto requiere una larga adaptación a una cultura que es extraña a la mayoría de los programadores.
2. Un programador debe aprender una extensa librería de clases antes de ser eficiente en el desarrollo de aplicaciones.
3. Dificultad en el diseño de clases.
  Una clase es una plantilla que se usa para crear nuevos objetos. La definición de clases es actualmente más un arte que una ciencia. Un error en el establecimiento de las jerarquías puede tener un efecto devastador en los proyectos software.
Herencia.
Se afirma que este es el concepto más potente de la POO, Sin embargo, se trata de un concepto limitado. La herencia es lineal y descendente. Pocos lenguajes soportan la herencia múltiple, es decir, que una clase herede (atributos y métodos) de dos o más clases. Lo normal es la herencia lineal, en la que una clase solo hereda de la clase padre.

Sin embargo, en la vida real la herencia múltiple es muy frecuente, pues los objetos se pueden clasificar de muchas maneras. Por ejemplo, los coches pueden ser: antiguos y no antiguos. Y también pueden ser deportivos, de lujo o familiares. En este caso las clases "deportivos", "de lujo" y "familiares" tienen dos superclases: antiguos y no antiguos.

La herencia lineal nos fuerza a categorizar las cosas de una sola forma. La herencia múltiple nos permite considerar los objetos como unión de las características de varias clases ya existentes.
Rendimiento.
En un sistema donde todo es un objeto y toda interacción se realiza mediante mensajes es intrínsecamente menos eficiente que el código procedural.
Reusabilidad.
La POO no ha logrado su objetivo de reusabilidad de componentes (clases y objetos) por su complejidad. Ello es debido principalmente a la herencia jerárquica, pues un objeto necesita la clase a la que pertenece y todas las clases superiores.

“El problema de los lenguajes orientados a objetos es que arrastran con ellos todo un entorno implícito. Quieres un plátano, pero lo que consigues es un gorila sosteniendo un plátano y la jungla entera” (Joe Armstrong, creador del lenguaje Arlang, en “Codes at Work”).
Dependencia del lenguaje.
Todavía no existe un LOO estándar. Los desarrollos realizados en un cierto LOO no son portables, por su diferente sintaxis y semántica. Una vez elegido el LOO, cambiar a otro puede ser difícil y costoso, porque estos lenguajes no soportan las funcionalidades por igual. Por ejemplo, C++ soporta herencia múltiple, mientras que Smalltalk no.

Además, algunos lenguajes son extensiones de lenguajes orientados a procedimientos (como C++) o diseñados bajo un paradigma diferente, por lo que quedan de alguna forma condicionados por el diseño original.
Inconsistencia lingüística y ambigüedad.
Es inconsistente llamar “objeto” a una entidad que realiza acciones. Sería más lógico (o tendría más sentido) llamarlo “sujeto”, pues los que realizan las acciones son los sujetos.
“Todo es un objeto”.
Nada escapa a esta interpretación. Hasta las expresiones aritméticas tienen su significado dentro de los objetos y los mensajes, de forma que, por ejemplo, en 3 + 7, el énfasis se pone en el objeto (3) que recibe el mensaje +7).

Esto supone forzar a una uniformidad que no se sostiene. En efecto, la POO pone énfasis en la identificación y diseño de los objetos, lo que es correcto y apropiado al establecerse el enlace con un patrón básico de la mente, pero olvida otros patrones semánticos, que quedan sujetos a cada LOO particular. La solución a este problema pasa por extender la semántica.

Según Alexander Syepanov −diseñador e implementador de componentes software de la Standard Template Library de C++, e impulsor de la programación genérica−, “decir que todo es un objeto es no decir nada en absoluto”.

El concepto de “objeto” es, en sí mismo, ambiguo. “La frase ‘orientación a objetos’ significa muchas cosas. La mitad son obvias y la otra mitad son equivocaciones” (Paul Graham, conocido por sus trabajos en Lisp).
Interfaz estática.
Pese a haberse aumentado la flexibilidad del interfaz (mediante la posibilidad de invocar diferentes métodos), los objetos son sensibles solamente a ciertos tipos de mensajes. La interfaz está previamente definida, no puede cambiarse y es, por lo tanto, estática.

Además los métodos de un objeto se pueden considerar como mera agrupación de procedimientos tradicionales. Y los mensajes no difieren conceptualmente de las llamadas tradicionales excepto por un término adicional, que es el nombre del objeto destinatario del mensaje (selector).
Falta de control.
No existe control completo del proceso, pues existe un gestor de mensajes, un itermediario encargado de pasar los mensajes de un objeto a otro.

De hecho, en cada mensaje a procesar, el gestor busca el selector en la clase del objeto receptor, luego en la superclase, en la superclase de la superclase, etc. hasta llegar a la clase raíz. Y eso suponiendo el caso simple de herencia lineal.
El problema de los datos comunes.
Cuando hay datos comunes a varios objetos, la solución que existe es antinatural: crear una clase u objeto y pasarle mensajes para crear o modificar esos datos comunes.
Estructura de procesos.
La POO no permite modelar la concurrencia de procesos, un tema muy importante en los sistemas software.

Historia de la POO

La POO tiene su origen en Simula 67 (una revisión de Simula I), un lenguaje de programación diseñado para realizar simulaciones discretas. Este lenguaje estableció los conceptos básicos de la POO.
El concepto de “objeto” fue refinado en Smalltalk, un lenguaje puro orientado a objetos desarrollado en Xerox PARC mediante Simula 67. En Smalltalk, los objetos son dinámicos: se pueden crear y modificar en tiempo de ejecución. Gracias a Smalltalk, la POO alcanzó gran popularidad.

Smalltalk es el paradigma de la orientación a objetos, de la misma forma que Lisp es el paradigma de la programación funcional. Smalltalk es considerado “el Santo Grial” de la POO, Todo lenguaje orientado a objetos se compara siempre con Smalltalk.

Alan Kay es el creador de Smalltalk. Comenzó a desarrollarlo en 1969 y estuvo disponible al público en 1980. Su creador se inspiró básicamente en tres principios:
1. Todo es un objeto. Kay se inspiró en el lenguaje Logo, creado por Seymour Papert y su equipo en 1968 en el MIT. En Logo solo hay un objeto, que es la tortuga. Enviando mensajes a este objeto se obtienen diferentes comportamientos (movimientos).
2. El meta-principio monádico y minimalista de Leibniz: “Para conseguir todo de nada, solo se necesita encontrar un principio”.
3. El principio de Platón, expresado en Fedro: “Dividir las cosas en clases donde están las uniones naturales, y no tratar de romper ninguna parte a la manera de un mal escultor”. Kay simplificó o abrevió esta idea en “Dividir la naturaleza en sus uniones”.
Estos principios los desarrolló en las siguientes ideas como fundamentos de Smalltalk:
1. Todo es un objeto.
2. Los objetos se comunican mediante mensajes.
3. Los objetos tienen su propia memoria, que consta de otros objetos.
4. Todo objeto es un ejemplar o instancia de una clase, que es también un objeto.
5. Una clase contiene atributos y métodos (procedimientos) que definen el comportamiento de los objetos de esa clase.
6. Las clases están organizadas en forma de árbol jerárquico y heredan los métodos y los atributos de las clases superiores.
A mediados de los años 1980s, la POO se convirtió en el paradigma de programación dominante. Este paradigma se consolidó gracias al auge de las interfaces gráficas de usuario (IGU, GUI en sus siglas en inglés), para las cuales la POO se adaptaba especialmente.

Actualmente existe una gran variedad de lenguajes de programación que soportan la orientación a objetos, y pueden dividirse en las siguientes categorías:
1. Lenguajes OO puros, como Smalltalk, Self, Ruby y Eiffel.
2. Lenguajes OO con elementos procedurales, como Java, C#, VB.Net y Object Pascal.
3. Lenguajes procedurales extendidos a OO, como Pascal, Perl, PHO y Matlab.
4. Lenguajes de tipos abstractos de datos, pero sin todas las características de la OO, como Modula-2, CLU y JavaScript.
5. Lenguajes “camaleónicos” que soportan múltiples paradigmas, como Tcl.
Hoy día, Java es el lenguaje orientado a objetos más difundido y utilizado.

POO vs. POD (Programación Orientada a Datos)

En POO, todo es un objeto, que integra datos (encapsulados) y código (los métodos). En POD todo es un dato: el código y los datos tiene la misma estructura. Esto tiene la ventaja de su flexibilidad, pues permite modificar fácilmente el código y realizar multiprogramación en general. EN POD no hay encapsulación ni polimorfismo.

El ejemplo más representativo es el lenguaje Lisp [Winston & Berthold, 1989], donde datos y código tienen la misma estructura: la lista. Otros ejemplos de POD son los lenguajes Awk y Sed [Dougherty, 1990].

MENTAL y la POO
Comparaciones POO - MENTAL

Clases y objetos.
En MENTAL, las clases se definen mediante expresiones genéricas. Los objetos son instancias de las expresiones genéricas con argumentos concretos.
Objetos vs. Expresiones.
En POO todo es un objeto. En MENTAL, todo es una expresión, donde se diluye la distinción entre datos y procesos porque toda expresión se evalúa.
Mensajes vs. Espacio abstracto.
La comunicación entre objetos vía mensajes es complejo. Más simple es utilizar el espacio abstracto (la memoria) como medio de comunicación.
Datos y código.
En POO se integran datos y código. En MENTAL En este sentido, MENTAL se puede considerar un lenguaje orientado a datos.se unifican en el sentido de que ambos tienen la misma estructura.
Herencia jerárquica vs. Compartición.
MENTAL utiliza un concepto más general y flexible que la herencia jerárquica (descendente): la compartición, que se expresa de manera muy simple mediante una expresión genérica. La compartición puede realizarse con todo tipo de expresiones. Esto supone mayor libertad expresiva y combinatoria.
Polimorfismo.
En POO, la semántica puede variar en función de los argumentos o del objeto receptor del mensaje. En MENTAL, los componentes de las primitivas pueden ser de cualquier tipo, pero la semántica se mantiene.
Eventos.
En POO, los eventos pueden ocurrir antes y después del envío de un mensaje. En MENTAL, los eventos pueden ocurrir antes y después de la evaluación de una expresión.
Encapsulamiento.
En POO hay encapsulamiento porque se utiliza abstracción de datos. En MENTAL no hay encapsulamiento, es un lenguaje trasparente. Lo que se oculta son las implementaciones de las primitivas semánticas.
Paradigma universal.
MENTAL es un lenguaje universal que refleja un paradigma universal, un paradigma capaz de expresar cualquier paradigma particular de programación basado en abstracciones, incluyendo los objetos.
Relación paradigma-lenguaje.
En MENTAL hay una relación estrecha y profunda entre paradigma y lenguaje, entre el paradigma universal y el lenguaje universal, pues ambos se reflejan mutuamente. En cambio, el paradigma POO no se refleja de manera directa en el lenguaje, pues cada lenguaje lo interpreta de manera diferente.
Paradigma definitivo.
La POO no es el “paradigma definitivo”, es solo un paradigma más y el más restrictivo. Los objetos no es la única forma de ver el mundo. MENTAL es el paradigma definitivo, un paradigma basado en 12 principios, grados de libertad, dimensiones o arquetipos de la conciencia. Supone la primacía de la conciencia, de lo profundo frente a lo superficial. La abstracción de objetos esta basada o inspirada en el mundo de los objetos materiales. Pero los arquetipos de la conciencia están en un nivel más profundo y subyacen a el mundo físico (externo) y al mundo mental (interno). La programación es una actividad mental. La manera más sencilla y directa de programar es utilizar los grados de libertad mental o arquetipos de la conciencia.

Ejemplos simples de compartición

⟨( f(x y) = (x+y x*y) )⟩ ⟨( g(x) = f(x 3) )⟩

Se define una función (g) que depende de otra (f).

g(7) // ev. f(7 3) ev. (7+3 7*3) ev. (10 21)
⟨( f(x) = (2*x + 1) )⟩ ⟨( g(x) = (3*x + 5) )⟩ ⟨( h(x) = (f(x) + g(x) + 7) )⟩

En este caso, una función está definida a través de dos funciones.
(x = (3 5 7)) ( y = (a ⟨x⟩ b) // ev. (a (3 5 7) b) ev. (a 357 b) ( z = (a ⟨x⟩∪⟨x⟩ b) // ev. (a (3 5 7 3 5 7) b) ev. (a 357357 b)

En este caso, la expresión x está compartida por y y por z. Cambios en x afectan inmediatamente a y y z.

(x = (1 2 3) y // ev. (a 123 b) z // ev. (a 123123 b)
(x = 123) (y = 456) ( z = (⟨x⟩ ⟨y⟩ ⟨x⟩+⟨y⟩) // ev. (123 456 579)

En este caso, las expresiones x e y están compartidas por z. Cambios en x y/o y afectan inmediatamente a z.

(x = 10) (y = 20) z // ev. (10 20 30)

Ejemplo de clase

Definimos una clase X con la que se pueden crear y modificar conjuntos de números enteros, con los métodos siguientes:

Crear un conjunto C.
Añadir un número a un conjunto C.
Eliminar un número n de un conjunto C.
Sustituir un número n1 por otro n2 de un conjunto C.
Eliminar un conjunto C.
Obtener el valor de un conjunto C.

Los posibles formas de invocar a la clase X son:

X/(CrearConj Nombre Valor)
X/(AñadirNum Nombre n)
X/(EliminarNum Nombre n)
X/(SustituirNum Nombre n1 n2)
X/(EliminarConj Nombre)
X/(ValorConj Nombre)

siendo:

n

n1

n2

n1

Especificación:


  ⟨( X/p =


   (


(nombre = p\2)


(valor = p\3)


( (p\1 = CrearConj) → 


         (nombre! = valor)¡ )




( (p\1 = AñadirNum) → 


          (nombre! = {nombre↓ valor})¡ )
 




( (p\1 = EliminarNum) → 


          (nombre! = nombre/(valor=θ)¡ )




( (p\1 = SustituirNum) → 


           (valor2 = p\4)
           (nombre! = nombre/(valor=valor2)¡ )




( (p\1 = EliminarConj) → 


           ( (Nombre! = θ)¡ )




( (p\1 = ValorConj) → 


           ( (Nombre!)¡ )


    )                     


  )⟩

Ejemplos:


X/(CrearConj A {1 2 3})     // A={1 2 3}



X/(CrearConj B {11 12 13})  // B={11 12 13}



X/(CrearConj C {21 22 23})  // C={21 22 23}



X/(AñadirNum A 9)           // A={1 2 3 9}



X/(EliminarNum B 13)        // B={11 12}



X/(SustituirNum A 3 8)      // A={1 2 8}



X/(EliminarConj C)              // C=θ



X/(ValorConj A) // ev. {1 2 3 9)         



X/(ValorConj B) // ev. {11 12}



X/(ValorConj C) // ev. θ

Bibliografía

Alfonseca, Manuel; Alcalá, Alfonso. Programación Orientada a Objetos. Teoría y técnicas OOP para el desarrollo de software. Anaya Multimedia, 1992.
Booch, Grady. Object Oriented Design with Applications. The Benjamin/Cummings Publishing Co., 1991.
Bouzeghoub, Mokrane; Gardarin, Georges; Valduriez, Patrick. Objetos. Conceptos, Métodos, Herramientas. Eyrolles, Ediciones Gestión 2000, 1995.
Budd, Timothy. An Introduction to Object-Oriented Programming. Pearson, 2001.
Cox, Brad. Object Oriented Programming: An Evolutionay Approach. Addison Wesley, 1991.
Ceballos Sierra, Francisco Javier. Programación orientada a objetos con C++. Ra-Ma, 2003.
Dougherty, Dale. Sed & Awk. O’Reilly & Associates, Nov. 1990.
Joyanes Aguilar, Luis. Programación orientada a objetos. McGraw-Hill Interamericana de España, 1996.
Meyer, Bertrand. La nueva cultura del desarrollo del software. Systems, pp. 12-13, 10 Sept. 1990.
Winblad, Ann L.; Edwards, Samuel D.; King, David R. Software Orientado a Objetos. Addison-Wesley/Díaz de Santos, 1993.
Winston, Patrick; Horn, Berthold. Lisp. Pearson, 1989.
Wu, Thomas C. Introducción a la programación orientada a objetos con Java. McGraw-Hill Interamericana de España, 2001.